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Abstract. Automated theorem provers are used in extended static check- 
ing, where they are the performance bottleneck. Extended static checkers 
are run typically after incremental changes to the code. We propose to 
exploit this usage pattern to improve performance. We present two ap- 
proaches of how to do so and a full solution. 



1 Introduction 

Extended static checking [T] is a technology that makes automated theorem 
proving relevant to a wide group of programmers. The architecture of an Ex- 
tended Static Checker (ESC) is similar to that of a compiler (see Fig. [T|). It 
has a front-end that translates high-level code and specifications into a simpler 
intermediate representation, and a back-end that formulates first order logic 
formulas as queries for a theorem prover. The queries are called verification con- 
ditions (VCs). If the ESC is sound then the VC is Unsat only if the code meets 
its specifications; if the ESC is complete then the program meets its specifica- 
tion only if the VC is Unsat. ESC/Java2 [T] is an ESC that was designed to 
be unsound and incomplete (as a tradeoff to make it more usable in practice); 
Spec # [2] is an ESC that was designed to be sound. 

In this article we shall assume an ideal ESC that is both sound and complete. 
Automated first order theorem provers used in extended static checking are 
incomplete: They cither find a proof that a formula is Unsat or they give an 
assignment that probably satisfies the formula. As a result, even if the ESC is 
sound and complete, spurious warnings are possible. 
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Fig. 1. The architecture of an ESC 



The purpose of an ESC is to provide warnings that help programmers to 
write high-quality code. In practice it is used much like a compiler. Either the 
programmer runs it periodically or the Integrated Development Environment 
(IDE) runs it in the background. Because of these usage patterns, performance 
is quite important. The bottleneck is the prover. Luckily, the fact that the ESC 
is run often can be exploited since it means that the program does not change 
much between two runs. Compilers already exploit this by doing incremental 
compilation ESCs do checking in a modular way, method by method. Never- 
theless, once the contract of a method is altered all its clients must be rechecked. 
In such a scenario the VCs of the clients do not change much. 



// blank line // (1) 

class Day { 

//@ ensures 1 <= \result && \result <= 12; 
public abstract int getMonthQ; 



//@ ensures 1970 <= \result; 
//(§ ensures \result <= 2038; 
public abstract int getYear(); 

//<§ ensures 1 <= \result && 
public abstract int getDay(); 

//<§ ensures 1 <= \result; 
//@ ensures \result <= 366; 
public int dayOfYear() { 
int offset = 0; 



// (2) 



\result <= 31; 



// (3) 



if (getMonth() > 1) offset += 31 
if (getMonthQ > 2) offset += 28 
if (getMonthQ > 3) offset += 31 
if (getMonthQ > 4) offset += 30 
if (getMonthQ > 5) offset += 31 
if (getMonthQ > 6) offset += 30 
if (getMonthQ > 7) offset += 31 
if (getMonthQ > 8) offset += 31 
if (getMonthQ > 9) offset += 30 
if (getMonthQ > 10) offset += 31; 
if (getMonthQ > 11) offset += 30; 
boolean isLeap = getYear() % 4 == && 

(getYearQ % 100 != |] getYear() % 400 
//<§ assert offset <= 335; // (4) 

if (isLeap && getMonthQ > 2) offset++; 
return offset + getDayQ; 



o); 



Fig. 2. Typical evolution of annotated Java code 



This paper (1) argues for the importance of using techniques analogous 
to incremental compilation in software verification, (2) formalizes the problem 
and explores possible solutions (Sect. [5]), (3) presents a specific solution that 
works exclusively inside an automated theorem prover (Sect. [3]), in the process 
(4) presents a technique to heuristically determine similarities between formulas, 
and (5) gives a mechanically verified proof for the correctness of a part of the 
specific solution presented. 

2 Discussion and Definitions 

The problem in a nutshell is how to do incremental extended static checking. 
We shall explore the solution space and then we will see in detail a particular 
solution, including some experimental data. 

Consider the JML-annotated Java code from Fig. [2] When checking the 
method dayOfYear the ESC will assume the implicit empty precondition holds 
and will try to prove the postcondition. It will also try to prove all the explicit 
and implicit assertions in the body. When the method getMonth is called the 
ESC inserts (implicit) assertions for its preconditions followed by assumptions 
for its postconditions. Moreover, the ESC will introduce assertions that ensure 
the absence of runtime exceptions. For example, the receiver object of a method 
call is asserted to be nonnull. 

Notice the lines marked by (1), (2), (3), and (4). Adding these lines represents 
typical edits that can be done on annotated source code. For example, line 
(3) is a newly added postcondition. An incremental VC would only check if 
this new assertion holds, provided that the last VC was Unsat. It is somehow 
cumbersome to formulate the problem precisely at the source code level. We 
can be more precise by descending at the level of an idealized intermediate 
representation, a Dynamic Single Assignment (DSA) graph. 

Definition 1 (DSA graph) The DSA graph of a method is a directed acyclic 
(control flow) graph. Its vertices are 1,2,... and they are labeled respectively by 
the first order logic formulas 4>i, §1-, ■ ■ ■■ A vertex represents either an assertion 
(in which case we say it is blacky or an assumption (in which case we say it is 
white,). We denote the set of vertices that are predecessors of v by vci(v) and the 
set of successors of v by out(i>). The in-degree of v is\ in(v)| and the out-degree 
is | out(f)|. The nodes with in-degree zero are called initial nodes; the nodes with 
out-degree zero are called final nodes. 

The assertions model the postconditions of the verified method and the checks 
inside its body (such as the check that an index in an array access is in-bounds, 
a receiver of a method call is nonnull, the preconditions of a called method hold, 
explicit JML assertions, and so on). The assumptions model postconditions of 
the called methods and semantics of the Java language (including properties 
ensured by the type system). 

For this presentation we simply assume that the intermediate representation 
is obtained from the source code by some technique, without committing to any 



one in particular. The curious reader can start exploring the subject from other 
papers j2l4!5l6j . 

The VC is generated from the intermediate representation. The particular 
algorithm used has a big impact on performance |7l5j . Here we only present a 
conceptually simple technique that illustrates well the general form VCs have in 
practice. 

Definition 2 (behaviors) Vertices have associated preconditions denoted by 
oi.i,a-2, . . ., postconditions denoted by f3\, fa, . . ., and wrong behaviors denoted 
by 71, 72, . . . For all i we have 



I T for initial nodes 

\\/ v ein(v ) @j f or non-initial nodes 
[ii = cti A <j>i 

{cti A —i(j>i for assertions 
_L for assumptions 

Definition 3 (verification condition) The verification condition is 

i> = \Jli (4) 

i 

The wrong behaviors are something we want to avoid, therefore we ask the prover 
if all the wrong behaviors are impossible which is the same as asking if the VC 
is Unsat. If it is, then the ESC concludes that all the assertions are valid and 
the method is correct. The basic idea behind the more efficient techniques of 
generating VCs is to generate factored form. 
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tpi = 01 A -102 


tp2 = (01 A -^<f> 2 ) V (0i A 02 A ^0 3 ) 


4>' 2 — 01 A 4>2 A -103 



Table 1. Simplification example 



The problem can now be stated as follows: Given two similar formulas "01 
and ip2, find a formula ip' 2 that is Unsat if and only if 0^ is Unsat, provided 
that tpx is Unsat. An example is given in Table [TJ The following equations show 
step by step how to compute ip2 from its corresponding DSA graph. 



ai = T 
a 2 = 4>i 
U3 = 01 A 2 



01 = ^1 

02 = 01 A 02 

/?3 = 01 A 02 A 03 



71 = ± 

72 = 01 A -102 

73 = 01 A 02 A ^03 



(5) 
(6) 
(7) 



To make the example concrete the reader might wish to plug in 0i = x > 2 and 

02 = x > 1 and 03 = x > 0. 

Note that if> 2 — 0i A ^03 is sound too, but we do not want to drop parts of 
the formula that are assumptions because they can make the proof easier. The 
simplified formula can be obtained in two ways. One is to replace the assertions 
that appear in both DSA graphs by assumptions and generate the VC for the 
modified DSA graph; the other is to work directly on the formulas ipi and ip 2 - 
In this paper we will explore in greater detail the latter. 

In both approaches, a solution has to solve two subproblems. First, we must 
find a correspondence between parts of the two DSA graphs (or formulas). Sec- 
ond, we must simplify one of the DSA graphs (or formulas). The methods we 
present in the next section for finding a correspondence between parts of the 
formulas can be partially reused for finding a correspondence between parts of 
the DSA graphs. Simplifying a formula is harder than changing assertions into 
assumptions, but on the other hand it is independent of the particular interme- 
diate representation used. 

3 Pruning First Order Formulas 

One subproblem is to find a correspondence between parts of ip\ and parts of ip 2 . 
We substitute (some) uninterpreted constants in ipi by uninterpreted constants 
that appear in "02- We also normalize the formulas with respect to commutative 
operators (Fig. [3]). We also use hash-consing [819] so later terms are simply 
compared by reference equality. 

Note that if ipi is Unsat, then any substitution that renames uninterpreted 
constants leaves it Unsat. The only assumption we make in solving the second 
subproblem is that ipi is Unsat, so there is no 'right' or 'wrong' correspondence 
between old and new constants. It is true, however, that for different substitu- 
tions of constants we will end up with different results ip 2 , some bigger and some 
smaller. Also we need to remember not to rename interpreted constants (such 
as 1 and 42). 

Assuming that all constants that are 'the same' have the same name in 
as in "02 would not allow us to prune the VC (to _!_) when the programmer only 
renamed a variable. (Variables in the program appear as uninterpreted constants 
in the VC.) Even worse, the ESC encodes extra information in identifiers [10] 
that changes, for example, when a new line is added to the source Java file. 
Despite these variations, a human that sees both ipi and tp 2 is generally able to 
say which sub-term corresponds to which sub-term. So there are good chances 
to find a heuristic that works well! 



class Term 
public Name : string 
public Children : list [Term] 
def Sort Term (t) 

def CompareTerms(a, b) 
def nc = a.Name.CompareTo(b.Name) 
if (nc != 0) nc 

else LexicographicCompare(a. Children , b. Children, CompareTerms) 
def children = t. Children . Map(Sort Term) 

if (IsCommutative(t)) Term(t.Name, t. Children . Sort(CompareTerms)) 

else Term(t.Name, children) 

def oldVC = SortTerm(oldVC) 
def newVC = SortTerm(newVC) 

Fig. 3. Normalizing queries 



We only consider renaming of uninterpreted constants because of the partic- 
ular algorithm used to build VCs. If some of the function symbols would also 
need to be renamed, the algorithm can be easily extended by the standard tech- 
nique of introducing a special function symbol apply, and replacing /(ti, . . . , t n ) 
with apply(f,ti, . . .,t n ). 

The heuristic we use to find a good substitution assigns a similarity value to 
each pair of (old, new) constants and then finds a maximum bipartite matching 
(using the Hungarian method [11]) between the old and the new constants. A 
complete bipartite graph is constructed from the set Vi of uninterpreted con- 
stants that appear in ipi and the set Vi of uninterpreted constants that appear 
in ?/>2- Each pair (i, j) G V\ x V% has an associated weight, which in this case is 
the similarity of the two constants. A matching is a subset M C V\ x V2 such 
that for all pairs £ M and e M we have i = i' if and only if j = j' . 

The weight of the matching is the sum of the weights of all its elements. The 
similarity has two components: One is the length of the longest common subse- 
quence |12| of the two identifiers; the other, more important, is how many times 
the constants appear in similar positions in the two VCs. 

To measure similarity of position we use path strings |13j . A path string is a 
sequence of function symbols interleaved with the positions, on a path from the 
root of the term to a particular occurrence of a sub-term. For example f.2.g.\ 
is a path string for the occurrence of b in f(a,g(b,c)), and f.2.g.2 is a path 
string for c. We construct a stripped path string by treating logical connectives 
as function symbols, the entire formula as a term, and skipping positions for 
commutative symbols. For example A.V./.2.g.l is the stripped path string for b 
in (f(a,g(b)) V g(c)) A g(d). The environment of a constant c in a formula tp is 
the multiset of the stripped path strings for all occurrences of c in -0. Let E\ be 
the environment of x in tpi and E2 be the environment of y in tp2- The similarity 
of x and y is 2\E\ nii^l — — I-E2DI, where n is multiset intersection. Other 

measures, that take environments into account, are also possible. 



def Prune(pl : list [ list [Term]], p2 : Term) 
def pi = Flatten(pl) 

// I pi I is a DNF form, assumed to be UNSAT 
match (p2.Name) 
"and" => 
mutable common = [] 

foreach (x in pi) foreach (y in x) common = y :: common 
def pi = pl.Map(x => x.Filter(y => lcommon.Contains(y))) 
def p2 = p2. Children. Filter (y => lcommon.Contains(y)) 
if (pi. Contains ([])) Term("f alse", fj) 

else Term("and", common + p2.Map(x => Prune(pl, x))) 

| "or" => 

Term("or", p2. Children . Map(x => Prune(pl, x))) 
- => 

if (pl.Exists(x => Implies(p2, Term("and", x)))) Term ("false", []) 
else p2 
def prunedVC = Prune([[oldVC]], newVC) 



The algorithms are presented as Nemerle-like pseudocode [14j . Some obvi- 
ous optimizations are omittecd to improve readability. We also omit textbook 
algorithms. The algorithm for normalizing queries with respect to commuta- 
tive operators is given in Fig. [3J It recursively sorts arguments of commutative 
operators using lexicographic ordering. 

The second subproblem, simplification of formulas, is solved by the pruning 
algorithm in Fig. [4] The function Prune returns a formula equisatisfiablc to p2 
under the assumption that all elements of pi are Unsat. Elements of pi are 
conjunctions represented as lists. 

The function Implies explores the structure of two formulas and returns true 
only if the first is stronger than the second. The last branch is clearly correct: 
If p2 is stronger than a conjunct known to be Unsat then it is also Unsat. In 
the case that p2 is a disjunction we can treat its children independently. The 
case when p2 is a conjunction is more interesting. To understand why it works 
consider a small example. 



We write P(V'i,V'2) = f° r the result of pruning -02 under the assumption 
that ipi in Unsat. The common part of and ip2, as computed in the variable 
common in Fig. 2J is 02 A 04 . Pruning 0i V 03 knowing that 0i V 03 is Unsat 
results in _L. The formulas that appear in both ipi and ip2 can always be factored. 



Fig. 4. Pruning the VC 
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3 See |http : / /nemerle . org/svn . f x7/branches/f x8/Prun e"r . n| for all details. 



(0i A0 2 ) V (0 3 A 4 ) 
<H01 A 02 A 4 ) V (03 A 02 A 4 ) 

-^02 A 04 A (01 V 03 ) 



(11) 

(12) 
(13) 



Hence, we can always reduce the problem to the form 



02 



01 A 02 
01 A 03 

0iAP(0 2 ,0 3 ) 



(14) 
(15) 
(16) 



where 0j is the common part and 2 is what we assume to be Unsat while 
pruning 3 (see also Fig. [4}. In this example (j>[ = 02 A 04 and <j)' 2 — 3 = 
0i V 03. It is easy to see that the above is correct, by doing a case analysis 
on whether 0i(x) holds for some vector x. The formalization.] in Coq [15] of 
a simplified version of the pruning function emphasizes the main points of the 
proof. The formulas abstract theories by arbitrary predicates over the domain 
of uninterpreted constants. 

Inductive Formula : Type := 

FPred : (Dom — > Prop) — > Formula 

FAnd : Formula — > Formula — > Formula 

FOr: Formula — > Formula — > Formula. 
Fixpoint Eval (f : Formula) (x : Dom) {struct f} : Prop : = 
match f with 

I FPred p => p x 

I FAnd fa fb => Eval fa x /\ Eval fb x 
FOr fa fb => Eval fa x \/ Eval fb x 



The simplified version of the algorithm whose proof we check mechanically is 

Fixpoint Prune (pi p2 : Formula) {struct p2} : Formula : = 
match pi, p2 with 

I FAnd a b, FAnd aa c => if eq a aa then FAnd a (Prune b c) else p2 

I _, FOr a b => FOr (Prune pi a) (Prune pi b) 

I _, _ => if eq pi p2 then FPred PFalse else p2 
end. 

This function has two important invariants. 

Lemma PrunelnvA : forall pi p2 : Formula, forall x : Dom, 

(~ Eval pi x — > Eval p2 x — > Eval (Prune pi p2) x). 
Lemma PrunelnvB : forall pi p2 : Formula, forall x : Dom, 

(" Eval pi x — > Eval (Prune pi p2) x — > Eval p2 x). 



end. 



4 Available at http://radu.ucd.ie/hp/papers/ev.html 



These are proved by double induction on the structure of pi and p2. We use one 
extra fact. 



Lemma Unsatlmp : forall a b : Formula, 

( forall x : Dom, Eval a x — > Eval b x) — > Unsat b — > Unsat a. 

At this point we can prove that the algorithm is sound and complete. 

Lemma PruneSound : forall pi p2 : Formula, 

Unsat pi — > Unsat (Prune pi p2) — > Unsat p2. 
Lemma PruneComplete : forall pi p2 : Formula, 

Unsat pi — > Unsat p2 — > Unsat (Prune pi p2). 
Theorem PruneCorrect : forall pi p2 : Formula, 

Unsat pi -> (Unsat p2 <-> Unsat (Prune pi p2)). 
The algorithm in Fig. [3] is more efficient since it exploits the associativity 
and commutativity of the A and V operators. The worst case time complexity is 
O(mn), and arises when the formula known to be Unsat and the formula to be 
simplified have, respectively, the form 



where A and V are written as nary operators. Unfortunately, the average case 
that appears in practice is hard to describe. Experimental data from 20 cases 
suggests that the running time grows linearly with the size of the formulas. But 
we need more data before we can make a definite statement (see Sect. [5] for 
details). 

4 Case Study- 
In this section, we explain how the common way of editing programs affects the 
DSA and therefore also the VC and how pruning exploits the changes. 

Let us again consider the program from Fig. [21 We used ESC/Java2 to gener- 
ate VCs for a version without any of the lines marked (1), (2), (3), and (4). This 
was the base case. Next we ran it on a method with only line (1) added, only 
line (2) added and so forth. Finally we ran the pruning algorithm with the old 
formula being the base case and the new formula being being VC for a method 
with an added line. Table [5] lists three times for each such formula. The first is 
the time it takes to prove the formula using Simplify |16| ; the second is the time 
it takes to prune the formula; the third is the time it takes to prove the pruned 
formula. The reader can note that the running times of Simplify on the original 
formulas vary rather nondeterministically. In particular, one would expect the 
base case and the one with an added empty line to have the same running time, 
but they do not. The reason for this is a "butterfly effect" in the prover, where 
for example a slight change in the selection of a literal for a case split can cause 
large changes in the final shape of the proof search tree. 




(17) 
(18) 
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n times 
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Description 


Original 


Pruning 


Pruned 




base case 


20.91s 






(1) 


empty line 


17.59s 


2.23s 


0.01s 


(2) 


irrelevant postcondition 


16.91s 


2.31s 


0.06s 


(3) 


additional postcondition 


21.65s 


2.19s 


19.34s 


(4) 


assertion in the middle 


22.81s 


2.16s 


7.67s 



Table 2. Case study results 



The first edit operation (marked by (1)) is adding an empty line somewhere, 
or in general changing the locations of symbols. As ESCs often use location in- 
formation for encoding symbol names, the uninterpreted constants in the second 
VC are different than in the first one. Our algorithm generates a query that is 
just _L. 

The second edit strengthens the postcondition of a method get Year used in 
the verified dayOfYear method. Here, we are able to prune almost everything, 
i.e. the resulting query is propositionally Unsat. 

The third edit adds a postcondition to the verified method. We can imagine 
that the DSA graph gets one more black node at the end, so this is the only 
thing that should be verified now. In this case we do prune parts of the formula, 
it however fails to speed up checking. 

Finally the last edit adds an assertion near the end of the method. Here the 
heuristics work well and the time is reduced considerably. 

The dayOfYear method (Fig. [J) is an example of a case where the VC is rel- 
atively small (around 60 kilobytes), but hard to prove. This is due to the large 
number of possible paths in the method. There are other reasons methods can 
be hard to prove: methods can be more complicated, the specifications can be 
complicated, the modelling of the language can be more accurate (for example 
in multi-threading programs). All those scenarios are good for our pruning algo- 
rithm as it runs in polynomial time and can potentially save a lot of proving time. 
The bad case is when the formula is large, but not that hard to prove. In par- 
ticular it sometimes happen that most of the time is spent just reading/writing 
the formula and doing basic preprocessing, like skolcmization. 

5 Related and Future Work 

The work presented here parallels the work done in the compiler community un- 
der the name incremental compilation. In the context of software verification by 
theorem proving the term incremental verification is taken — it refers to the pro- 
cess of proving stronger assertions using weaker ones as lemmas [17j . Hence, we 
use the distinct term edit and verify for the related idea of proving only what has 
not been proven before, and doing so automatically. In the context of interactive 
theorem proving the term proof reuse is used for a similar technique [18j . 



A Program Verification Environment (PVE) is the same for an ESC, as an 
Integrated Development Environment (IDE) is for a compiler. It provides an easy 
to use interface to the tool. As incremental compilation is very useful in IDEs, 
we expect Edit and Verify to be even more useful in PVEs. This is because 
static verification consumes much more resources than compilation. There is 
much research on software verification using PVEs, there is also vast amount of 
interest from the industry in PVEs. 

One of the goals of the Mobius research project Q]5] is to produce a PVE for 
Java. Penelope [5D] is an early PVE that processes a subset of Ada. Its designers 
chose to rely on interactive theorem proving. The KeY Tool [5T| is a modern 
PVE for Java that uses the same approach but differs in the mechanisms and 
theory of verification condition generation. Spec# [2] is a modern PVE for C# 
that uses automated theorem proving. ESC/Java2 |H22j is an ESC for JML- 
annotated [23] Java code. It produces VCs in the Simplify [T^ format and in the 
SMT format [H] for other automated theorem provers. It also generates VCs for 
the Coq interactive theorem prover |15| . 

Whether an ESC is considered a PVE or not depends chiefly on how well 
integrated it is with the editor. ESC/Java2 is integrated into Eclipse using a 
plugin. Spec^ is more tightly integrated into Visual Studio using a plugin. Work 
on incremental compilation [3J suggests that an even tighter integration leads to 
important performance benefits. 

There are two improvements that we will try in the near future. One is 
to prune the DSA graph. The other is to modify Fx7 [25] to produce a formula 
weaker than the query but still Unsat, and use that to prune subsequent queries. 
Another idea that is worth exploring is to integrate pruning more tightly not 
with the ESC but instead with the proving process. For example, we could save 
the relevance of specific axioms in the old proof, so they can be prioritized while 
searching for a proof of the new query. 

To assess the effectiveness of these improvements we need a better bench- 
mark. The amount of JML-annotated Java is still modest. Moreover, code from 
the version control history is not appropriate because the commit cycle is typ- 
ically much longer that the duration between two invocations of ESC/Java2. 
Therefore we need to collect such data ourselves and this is a time consum- 
ing effort. Such a benchmark would hopefully nicely complement the existing 
(very useful) Boogie benchmarks and SMT-COMP benchmarks [24]. A theo- 
retical analysis seems to require a good model for the type of queries that are 
produced as verification conditions. 

An idea very similar to the one explored in this paper did lead to interest- 
ing results in model checking [26] . the so called extreme model checking. Model 
checking is sometimes used together with unit testing and therefore it is run of- 
ten on code with minor modifications. Therefore, it is natural to take advantage 
of the results of previous runs. 



6 Conclusion 



We described the typical usage pattern of automated theorem proving in ex- 
tended static checking and two approaches that exploit it to improve perfor- 
mance. We gave a detailed solution that processes first order formulas. The im- 
plementation is a part of the Fx7 theorem prover [25] . It was tested on queries 
generated by ESC/Java2, without requiring any modifications to the latter. The 
other approach, working on the intermediate representation of the extended 
static checker, promises to be more efficient but requires a tighter integration of 
the prover with the checker. 

The first part of the solution is a heuristic that, given two formulas, finds 
which sub-terms of one formula correspond to which sub-terms of the other. 
This heuristic may prove to be a useful technique in solving related problems 
since it performs well and there is ample room for tuning. The second part of 
the solution is a formula pruning algorithm. This algorithm is proven correct, 
and part of the proof is mechanically verified. Its efficiency is reasonable because 
of the use of hash-consing and because formulas are normalized with respect to 
commutative operators. The pruned formulas are clearly easier to prove. 
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